Could you add a test verifying that sequences work? e.g. libfoo.[1,2] matches libfoo.1/libfoo.2, but not libfoo.3?

Hi @mayeut, I’d like to draw your attention to this PR for it can support wildcard exclude, which can support to exclude specific libs without knowing the detailed filename (e.g. to exclude /usr/local/cuda*, intentionally). This feature can reduce a large amount of my work, please let me know if you think it's a good idea to merge this so I can try to find some other way.

Thanks!

I also have a similar issue, where for example I need to exclude: libcudart-8774224f.so and libnvToolsExt-847d78f2.so from my wheels. Wildcards would certainly help here for building wheels across different docker containers.

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.48%. Comparing base (5ba0b78) to head (dc9900c).
Report is 1 commits behind head on main.

@@            Coverage Diff             @@
##             main     #508      +/-   ##
==========================================
+ Coverage   92.47%   92.48%   +0.01%     
==========================================
  Files          20       20              
  Lines        1289     1291       +2     
  Branches      250      250              
==========================================
+ Hits         1192     1194       +2     
  Misses         56       56              
  Partials       41       41              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Could you add a test verifying that sequences work? e.g. libfoo.[1,2] matches libfoo.1/libfoo.2, but not libfoo.3?

@emmatyping-nv I had previously abandoned this PR because #411 had given me the impression that the PyPA team didn't want this change, but since there now appears to be activity on it from the maintainers, I went ahead and added this test.

I had previously abandoned this PR because #411 had given me the impression that the PyPA team didn't want this change, but since there now appears to be activity on it from the maintainers, I went ahead and added this test.

I won't have time to re-review this properly before the end of the year, maybe @lkollar will ?
Given the high demand for this feature, we should find a middle-ground to allow wildcard while emphasizing that it should be used with caution (c.f. the comment in #411 where the feature would allow not to reflect dependencies properly in metadata).
One way would be to have a toggle to enable fnmatch with its help mentioning that proper metadata is the packager responsibility, possibly redirecting to #411.

I only added a comment in the help message in the end. Thanks @KyleFromNVIDIA

Thanks for resurrecting my PR and finalize it :)